![[Amazon FSx for NetApp ONTAP] ボリュームとSSDのサイジング方法を整理してみた](https://devio2023-media.developers.io/wp-content/uploads/2022/08/amazon-fsx-for-netapp-ontap.png)
[Amazon FSx for NetApp ONTAP] ボリュームとSSDのサイジング方法を整理してみた
ボリュームとSSDのサイジングはどのようにしたら良いんだろう
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)のボリュームとSSDのサイジングはどのようにしたら良いんだろうと思ったことはありますか? 私はあります。
最近よく相談を受けるので、自分流のサイジング方法を整理します。
いきなりまとめ
- ボリュームは「ある程度に広めにサイジングする」
- ボリュームのサイズに対する課金は発生しない
- ボリュームの拡張と縮小は数秒で完了する
- なるべく正確にボリュームをサイジングする場合は以下の式で行う
ボリュームサイズ(MiB) = 保存したいデータサイズ(GiB) / Snapshot Reserve / 0.7 × 1024
- SSDは「少なめにサイジングして、必要になったら拡張する」
- SSDのサイズに対して課金が発生するため
- SSDの拡張はできるが、縮小はできないため
- 最小値(1,024GiB)で作成して、使用率が80%を超えるようになったタイミングで都度SSDを拡張する形でも良い
- 構築のタイミングでなるべく正確にSSDのサイジングをしたい場合は以下の式で行う
最低限必要なSSDのサイズ(GiB) = ボリューム1で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / Snapshot Reserve(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01) + ボリューム2で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / Snapshot Reserve(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01) + ボリューム3で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / Snapshot Reserve(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01) + ... + ボリュームnで最低限必要なSSDのサイズ プロビジョニングするSSDのサイズ(GiB) = 最低限必要なSSDのサイズ(GiB) / (1 - 0.16) / 0.7 - ボリュームとSSDの使用率の監視をしよう
ボリュームのサイジング
基本方針
まずはボリュームのサイジングです。
基本方針は、「ある程度に広めにサイジングする」です。
この理由は以下2点になります。
- ボリュームのサイズに対する課金は発生しない
- ボリュームの拡張と縮小は数秒で完了する
そのため、「思ったよりボリュームのサイズを確保する必要があった」や「多めにサイズを設定し過ぎた」という場面に直面しても、後からサイズを調整して対応可能です。
あまりに過剰なボリュームサイズをオススメしない理由
そうなると「全てのボリュームをボリューム(FlexVolume)の上限である100TBでサイジングすれば良いじゃないか」と思われるかもしれません。
しかし、これはオススメしません。この理由は大きく2点あります。
- 利用者から100TB使えるように見えてしまい、100TB使用できると誤認させてしまう可能性があるため
- 全ボリュームの合計サイズがSSDのサイズ以上である場合にSSDの奪い合いが発生しやすいため
- SSDの空き容量に対してボリュームサイズが大きすぎるとバックアップが失敗するため
まず、1つ目の理由です。
100TBでサイジングした場合、利用者から見ると100TB利用できるように見えてしまいます。そうなると、利用者は100TB使えるものとしてデータを保存し始めると考えます。
「直ちに100TB書き込まれるか」と言われるとそうではありません。デフォルトではボリュームの空き容量がSSDの空き容量以上である場合、デフォルトではクライアントから確認できるボリュームの空き容量はSSDの空き容量となるためです、特に注意するのはLogical Space Reportingを有効にしている場合です。
Logical Space Reportingを有効にしている場合はSSDの空き容量が見えなくなります。そのため、利用者はSSDの空き容量を認識することができず、ボリュームの空き容量分だけ書き込めるように見えてしまいます。
次に2つ目の理由です。
以下記事で紹介している通りSSDはFSx for ONTAPファイルシステム内のボリュームで共有されています。
そのため、全ボリュームの合計サイズがSSDのサイズを上回っているとSSDの争奪戦となります。
SSDの空き容量がなくなると書き込みができなくなるので、「100TB使えるはずなのに、一切書き込んでいないが使用率が100%に見える」みたいなことが起こりえます。
階層化ポリシーをAutoにすることでアクセス頻度の低いデータブロックはキャパシティプールストレージに流れていきますが、冷却期間の最低値が2日なので、全くアクセスいないデータでブロックも2日はプライマリストレージ(SSD)に滞留することになります。
階層化ポリシーがALLであっても後述する通り、ファイルのメタデータで数%はプライマリストレージに残るため注意が必要です。
なお、SSDの使用率が98%以上になると階層化されなくなります。
SSD ストレージ階層の使用率が 98% 以上 – SSD ストレージ階層の使用率が 98% 以上になると、すべての階層化機能が停止します。ストレージ階層からの読み取りは引き続き可能ですが、階層への書き込みはできません。
3つ目の理由は、MIN(ボリュームの空き容量, SSDの空き容量) / ボリュームサイズ × (1 - Snapshot Reserve) × 100がVolume Full Threshold Percentの値を上回っている場合は、ボリュームのバックアップを取得することはできないためです。詳細は以下記事で紹介しています。
なるべく正確にサイジングする場合の手法
今までボリュームのサイズはある程度に広めに取っておいて良いが、あまりに過剰なサイジングはオススメしないというのを説明しました。
次に、なるべく正確にサイジングする場合の手法を説明します。
計算式は以下になります。
ボリュームサイズ(MiB) = 保存したいデータサイズ(GiB) / (1 - Snapshot Reserve) / 0.7 × 1024
保存したいデータサイズ(GiB)はそのままの意味です。そのボリュームに保存したいデータの量を示しています。その他のパラメーターについて説明します。
/ (1 - Snapshot Reserve)というのはSnapshot Reserve分を加味するために計算しています。ボリュームを作成するとスナップショットの領域としてボリュームサイズの5%分予約されます。こちらの領域には書き込むことはできないため、それを加味する必要があります。
/ 0.7というのはバッファーです。先述した通りあまりにもギリギリを攻める必要はないので、ある程度余裕を持ってサイジングをします。さらに余裕を持ちたいのであれば0.5など設定しても良いと思います。また、「保存したいデータサイズ」ではなく「保存を許可するデータサイズ」であれば、バッファーを加味しないのも良いと思います。
× 1024はGiBをMiBに変換するために付与しています。ボリュームのサイズはMiB単位で指定する必要があるため、単位を揃える必要があります。
保存したいデータサイズが10GiBでSnapshot Reserveが5%の場合、先ほどの式に当てはめると以下のようになります。
ボリュームサイズ(MiB) = 10 GiB / (1 - 0.05) / 0.7 × 1024
= 15,238 MiB
このようにサイジングすることで、10GiB書き込んだとしても4.8GiBほど余裕があります。
Storage Efficiencyを有効化している場合は、ここに重複排除やデータ圧縮によるデータ削減が効いてくるので、実際の空き容量にはさらに余裕が出てくると予想します。ただし、階層化ポリシーをALLにしている場合はポストプロセスの重複排除が効かないので注意が必要です。
基本的には上述の式で良いと考えますが、場合によってはより大きなサイズにする必要があります。
それは、ボリュームサイズに対して多くのディレクトリやファイルを作成する場合です。
最大でボリュームサイズの4KiB毎に応じて1つのinodeが作成されるため、それよりも多くのディレクトリやファイルを作成する必要がある場合は、ボリュームサイズを増やす必要があります。詳細は以下記事をご覧ください。
SSDのサイジング
サイジングの全容
続いてSSDのサイジングです。
基本方針は、「少なめにサイジングして、必要になったら拡張する」です。
この理由は以下2点になります。
- SSDのサイズに対して課金が発生するため
- SSDの拡張はできるが、縮小はできないため
縮小することができないため、誤って過剰にサイジングしてしまった場合などSSDのサイズを小さくしたい時はFSx for ONTAPファイルシステムを作り直すことになります。
これは大変手間です。そのため、SSDの拡張は慎重に行う必要があります。
私としては最小値(1,024GiB)で作成して、使用率が80%を超えるようになったタイミングで都度SSDを拡張する形でも良いのかなと思います。
ただ、構築のタイミングで正確にSSDのサイジングをしたいときもあると思います。
その時の式は以下になります。
最低限必要なSSDのサイズ(GiB)
= ボリューム1で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01)
+ ボリューム2で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01)
+ ボリューム3で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01)
+ ...
+ ボリュームnで最低限必要なSSDのサイズ
プロビジョニングするSSDのサイズ(GiB) = 最低限必要なSSDのサイズ(GiB) / (1 - 0.16) / 0.7
最低限必要なSSDのサイズの計算
まず、以下の式でボリューム毎に最低限必要なSSDのサイズを求めています。
最低限必要なSSDのサイズ(GiB)
= ボリューム1で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01)
+ ボリューム2で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01)
+ ボリューム3で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01)
+ ...
+ ボリュームnで最低限必要なSSDのサイズ
保存したいデータサイズ(GiB)はボリュームのサイジングをした時の値と全く同じです。
/ (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ)はSnapshot Reserve分です。階層化ポリシーによってスナップショットがどの階層に保存されるかは異なります。今回はSSDの使用量を求めたいので、スナップショットがプライマリストレージに保存される階層化ポリシーがNoneの場合のみを考慮しました。
正確にはAutoやSnapshot Onlyの場合も冷却期間が経過するまでプライマリストレージに保持されますが、冷却期間後はキャパシティプールストレージに階層化されるので、ここでは除外しました。
× プライマリストレージの割合は保存したいデータのうち、どの程度プライマリストレージに保存されるかを求めています。
それぞれの値の目安は階層化ポリシーによって変動します。
| 階層化ポリシー | プライマリストレージの割合 |
|---|---|
| Auto | 0.2 |
| Snapshot Only | 1 |
| All | 0 |
| None | 1 |
階層化ポリシーがAutoの場合の割合は、頻繁に読み書きするデータの割合によって変動します。今回はFAQに記載の20% = 0.2としました。
Q: データの何パーセントをキャパシティープールストレージに階層化できますか?
A: Amazon FSx は、キャパシティープールストレージに階層化できるデータの割合に制限はありません。可能な限り最高のパフォーマンスを実現するために、データセットの頻繁にアクセスされる部分を SSD ストレージに保存することをお勧めします。業界調査と顧客分析によると、平均して、頻繁に使用されるのはファイルの 20% で、80% はアクセスの頻度が低いことが示されています。
階層化ポリシーがSnapshot Onlyにするとスナップショットのみがキャパシティプールストレージに保存されるため、100% = 1としました。
階層化ポリシーがAllの場合は全てのデータがキャパシティプールストレージに階層化されるとして0としました。
階層化ポリシーがNoneの場合は全てのデータがプライマリストレージに保存されるとして100% = 1としました。
× (1 - データ削減割合)はAmazon FSx for NetApp ONTAPP(以降、FSx for ONTAP)のFAQで紹介されているFSx for ONTAのデータ圧縮と重複排除による効果を参考に設定します。
| ワークロードの種類 | 圧縮のみ | 重複排除のみ | 圧縮および重複排除 |
|---|---|---|---|
| 汎用ファイル共有 | 50% | 30% | 65% |
| 仮想サーバーとデスクトップ | 55％ | 70% | 70% |
| データベース | 65～70% | 0% | 65～70% |
| エンジニアリングデータ | 55％ | 30% | 75% |
| 地質地震データ | 40% | 3% | 40% |
こちらはあくまで目安なので、実際にどのぐらいデータ量が削減できるかは実際のワークロードによって異なります。試算することも難しいので、やってみなければ分からない要素でもあります。
+ 保存したいデータサイズ(GiB) × 0.01ファイルのメタデータサイズを加味した値です。平均ファイルサイズに応じてメタデータの割合が変動します。
| 平均ファイルサイズ | ファイルデータに対する、メタデータサイズの割合 |
|---|---|
| 4 KB | 7% |
| 8 KB | 3.50% |
| 32 KB 以上 | 1～3% |
抜粋 : SSD ストレージ容量の選択 - FSx for ONTAP
今回は小さめにサイジングするというポリシーの元、ファイルサイズに対して1%で見積もります。
メタデータはキャパシティプールストレージに階層化されず、常にプライマリストレージに保存されます。
データ移行時に移行先ボリュームのデータ階層化ポリシーを All に設定すると、すべてのファイルメタデータはプライマリ SSD ストレージ層に保存されます。ファイルメタデータは、ボリュームのデータ階層化ポリシーに関係なく、常に SSD ベースのプライマリ層に保存されます。プライマリ層とキャパシティプール層のストレージ容量の比率を 1:10 と仮定することをお勧めします。
また、ファイルのメタデータにStorage Efficiencyによる重複排除・圧縮は効きません。
ファイルメタデータはストレージ効率化による節約の恩恵を受けないことに注意してください。
保存したいデータサイズが10GiBで、階層化ポリシーがAuto、データ削減割合が20％の場合、最低限必要なSSDのサイズは先ほどの式に当てはめると以下のようになります。
最低限必要なSSDのサイズ(GiB) = ボリューム1で最低限必要なSSDのサイズ((保存したいデータサイズ(GiB) / (1 - Snapshot Reserve)(階層化ポリシーがNoneの場合のみ) × プライマリストレージの割合 × (1 - データ削減割合)) + 保存したいデータサイズ(GiB) × 0.01) = ボリューム1で最低限必要なSSDのサイズ(10 GiB × 0.2 × (1 - 0.2) + 10 GiB × 0.01) = 1.7 GiB
これで、SSDの最低限必要なサイズを求めることができました。
プロビジョニングするSSDサイズの計算
まだ最低限必要なサイズを求めただけなので、この値でSSDをプロビジョニングするとSSDの使用率が100%となってしまいます。また、ONTAPが使うオーバーヘッドも加味されていません。
そのため、以下の式でプロビジョニングするSSDサイズの計算をします。
プロビジョニングするSSDのサイズ(GiB) = 最低限必要なSSDのサイズ(GiB) / (1 - 0.16) / 0.7
/ (1 - 0.16)はFSx for ONTAPのオーバーヘッドです。
プロビジョニングされたSSDの内、11%がONTAPが動作するための領域として予約され、5%がアグリゲートスナップショット用で予約されています。
NetApp ONTAP ソフトウェアオーバーヘッド
他の NetApp ONTAP ファイルシステムと同様に、ファイルシステムの SSD ストレージ容量の 16% は、次のように ONTAP のオーバーヘッドに割り当てられています。
- 11% は NetApp ONTAPソフトウェアに割り当てられています。
5% は、ファイルシステムの両方のファイルサーバ間でデータを同期させるために必要な、集約スナップショット用に確保されています。
ONTAP が予約した SSD 容量は、ファイルの保存には使用できません。
こちらはNetAppの以下KBでも紹介されています。
/ 0.7はバッファーです。SSDの使用率は80%を下回っていることが推奨されています。これは90%になると、階層化ポリシーがAutoとSnapshot Onlyの時に動作していたキャパシティプールストレージからプライマリストレージへの書き戻しが発生しなくなるためだと予想します。
注記
SSD ストレージ層のストレージ容量使用率が 80% を超えないようにすることをお勧めします。これにより、階層化が適切に機能し、新しいデータのオーバーヘッドが発生します。SSD ストレージ層のストレージ容量使用率が一貫して 80% を上回っている場合は、SSD ストレージ層の容量を増やすことができます。詳細については、「SSD ストレージ容量と IOPS の更新」を参照してください。
FSx for ONTAP では、次のストレージ容量のしきい値を使用してボリュームの階層化を管理します。
- SSD ストレージ階層の使用率が 50% 未満 — このしきい値では、SSD ストレージ階層は十分に活用されていないと見なされ、[All] (すべての) 階層化ポリシーを使用しているボリュームのみが容量プールストレージにデータを階層化しています。[Auto] (自動) ポリシーと [Snapshot-only] (Snapshot 専用) ポリシーが適用されているボリュームでは、このしきい値ではデータが階層化されません。
SSD ストレージ階層の使用率が 50% を超える — [Auto] (自動) および [Snapshot-only] (Snapshot 専用) の階層化ポリシーが適用されたボリュームでは、階層化の最小冷却日数設定に基づいてデータが階層化されます。デフォルト設定は 31 日間。
SSD ストレージ階層の使用率が 90% 以上 – このしきい値では、Amazon FSx は SSD ストレージ階層のスペース確保を優先します。[Auto] (自動) および [Snapshot-only] (Snapshot 専用) ポリシーを使用するボリュームを読み取る場合、容量プール階層のコールドデータが SSD ストレージ層に移動されなくなりました。
SSD ストレージ階層の使用率が 98% 以上 – SSD ストレージ階層の使用率が 98% 以上になると、すべての階層化機能が停止します。ストレージ階層からの読み取りは引き続き可能ですが、階層への書き込みはできません。
70%ほどあれば、しばらくは90%を超えることは少ないのではと予想します。ただし、階層化ポリシーがAllの場合であっても一旦はSSDに書き込まれるので、大量の書き込みがある場合は注意が必要です。
アクティブなデータセットとすべてのファイルメタデータに加えて、ファイルシステムに書き込まれたすべてのデータは、容量プールストレージに階層化される前に、最初に SSD 階層に書き込まれます。これは、SnapMirror を使用して [All] (すべての) data 階層化ポリシーが設定されたボリュームにデータを転送する場合を除いて、ボリュームの階層化ポリシーに関係なく当てはまります。
また、階層化ポリシーでAutoやSnapshot Onlyの場合も、冷却期間が経過する(最低2日)まではプライマリストレージに滞留するので注意が必要です。
SSDの最低限必要なサイズが1.7GiBである時に、プロビジョニングするSSDのサイズは先ほどの式に当てはめると以下のようになります。
プロビジョニングするSSDのサイズ(GiB) = 最低限必要なSSDのサイズ(GiB) / (1 - 0.16) / 0.7
= 1.7 GiB / 0.84 / 0.7
≒ 2.89 GiB
プロビジョニングするSSDのサイズは2.89 GiBであることがわかりました。SSDのサイズは1GiB単位なので、切り上げで3GiBになります。
ただ、FSx for ONTAPファイルシステムのSSDの最小は1,024GiBです。それ未満の値は設定できないのでご注意ください。
運用の中で最適なサイズを見つけよう
自分なりのAmazon FSx for NetApp ONTAPのボリュームとSSDのサイジング方法を整理してみました。
細かい式も用意しましたが、最初はスモールスタートで、運用の中で最適なサイズを見つけていくことが良いと思います。
そのためにもボリュームとSSDの使用率の監視はしておいた方が得策です。
なお、SSDの拡張は1度拡張すると6時間は拡張できないので注意が必要です。データ保存量が大幅に増える見込みがある場合は、1度に大きめのサイズを拡張する必要があります。
[Storage capacity minimum increase] (最小値の増加) - 各 SSD ストレージ容量の増加は、ファイルシステムの現在の SSD ストレージ容量の最低 10％ で、最大許容値の 196,608 ギビバイト (GiB) までである必要があります。
増加間の時間 - 最後の増加がリクエストされてから 6 時間、またはストレージの最適化プロセスが完了するまでのどちらか長い期間は、ファイルシステムのストレージ容量をさらに増やすことはできません。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] Amazon Bedrock Agents のメモリ保持期間が最大 30 日から 365 日に変更されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-e3065182082062711612153bbdcf1d96/c04359de689df2f56eb066576ab63fb5/amazon-bedrock)
![[アップデート]Amazon Connect のキューとルーティングプロファイルを管理コンソールから削除できるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-a14da8621c55bd17addadcead8e0e00f/c928a36480d9593938e8d8f65ba92537/amazon-connect)
![[アップデート] Amazon QuickSight のデータセットでユニークキーが設定出来るようになったので挙動を検証してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-19e77b9a51519e08b94d0f688c125729/4f439c75e1ee56c70e315fa46fa45f81/amazon-quicksight)
